The overarching goal is an experimental system to make ActivityPub federation stuff clearer for devs, sysadmins and advanced users.
The documentation is incomplete and the code is really not OK! But they always say it's better to get stuff out the door for others to look at sooner. Maybe it inspires others to think about the Fediverse/ActivityPub in weird new ways!
Very interesting. It would certainly make doom scrolling harder. Email always feels more personal, like each message was sent specifically to me for a reason. As opposed to feeds, which feels like looking at cars as they drive by.
I think this system pushes against those boundaries. This sort of concrete brainstorming at the edges is such a crucial part of software evolution, so thank you.
I would actually love this. I use email for everything, it is so nice to have everything come to the same place. Right now I follow a few Mastodon users via an RSS-to-Email service, but the problem with that is that you can’t follow private accounts/see followers-only toots. It would be great to have a full email bridge.
I was considering making this myself at one point. But I think one of the big problem with ActivityPub is that it describes a single particular account. So if my ActivityPub-email bridge was running you wouldn’t also be able to access a Mastodon UI and for example browse other posts. So my account would need to be email-only which would be missing UX for a lot of things (like commenting on a random post I was linked to).
What have I done?! My abomination of an idea of bridging my email and ActivityPub progresses. If you see this message, something is working! Comments replies are welcome as it's a good test of this system :) People keep saying ActivityPub is a lot like email. If it's so similar to email, could I use my email client to interact with the fediverse? Previously I did this by writing a SMTP interface to the Mastodon HTTP API. That worked. But as we probably know, the fediverse is not Mastodon; it's really ActivityPub. The real deal would be working with ActivityPub directly, not the Mastodon HTTP API. And that's now (mostly?) working! In shonky diagram form, sending looks like this: laptop --SMTP--> my_server --ActivityPub--> fediverse Replies look like this: fediverse --ActivityPub--> my_server --SMTP--> mailbox <--IMAP-- laptop my_server translates back and forth between ActivityPub messages and mail messages. For example given the message: Date: Wed, 6 Mar 2024 16:37:59 +1100 From: Oliver Lowe To: [email protected] Subject: test 2 test hello world! The following ActivityPub message is created: { "@context": "https://www.w3.org/ns/activitystreams", "id":"https://apubtest2.srcbeat.com/outbox/1709703480070628170", "type":"Note", "name":"test 2", "to": ["https://aussie.zone/c/localtesting","https://www.w3.org/ns/activitystreams#Public"], "cc": ["https://aussie.zone/c/localtesting"], "published":"2024-03-06T16:37:59+11:00", "attributedTo":"https://apubtest2.srcbeat.com/actor.json", "content":"test hello world!", "mediaType":"text/markdown" } There's still a lot of bugs (of course) and unimplemented bits (of course). I can't call this a proper fediverse service yet. I'm going to roll with this for a bit and see how it holds up.
@fediverse Fediverse user growth jumped to ~50'000'000 users. What happened ?
The FediDB Fediverse User Growth graph shows a significant jump in user count in February. Software distribution is also 81% other, and the biggest server is fediverse.hanbitgaram.com with 39 million users ! What happened ? https://fedidb.org/
Which is funny cuz I've never really been to any of those. No accounts and only visited IG a few times because something else linked there for some information.
Also, I didn't really notice Threads was succeeding.
I post about !boinc a bunch on mastodon hopefully to get some excitement from astrophysics folks, there’s tons of cool boinc projects doing astrophysics research. Science runs on twitter, and many scientists are desperately searching for an alternative, imo it’s only a matter of time before they all end up on mastodon or nostr.
Accessing Mastodon and the fediverse via email: https://www.olowe.co/tmp/fedimail.mp4
An experimental #IMAP and #SMTP interface.
I feel like #NNTP#Usenet interface would be more appropriate.
But gotta start somewhere!
Threading and replies work ok too (so far!).
Ha good eyes! :) I have basic receive-only working with Lemmy using a virtual file system interface I wrote (pkg.go.dev/olowe.co/lemmy). Just realised we actually spoke about this a while ago haha (lemmy.sdf.org/post/1035382 )
But synchronising to disk is super inefficient: too many API calls. Should subscribe using ActivityPub proper and store updates received as RFC 5322 messages.
From there we could serve the messages via NNTP. Then, finally, we could use nntpfs(4)
Oh wow thanks! :) One program syncs my home Mastodon timeline, with all replies, to a Maildir. Dovecot serves that over IMAP. Sending involves a custom SMTP server which reads the mail message and creates a post from it.
For Mastodon it was all about converting statuses (toots? Posts?) into RFC 5322 messages. Using the status’ ID as Message-Id in the message header is handy. Mail clients do the heavy lifting of rendering threads thankfully!
Link aggregators have a problem on the fediverse. The approach is server-centric, which has positives, but it also has major negatives.
The server-centric approach is where a community belongs to a certain server and everything in the world revolves around that server.
The problem is that it's a centralized formula that centralizes power in a the hands of a whichever servers attract the most users, and potentially breaks up what might be a broader community, and makes for a central point of failure.
Right now, if [email protected] and [email protected] talk on [email protected] then a lot of things can happen to break that communication. if c.com defederates b.com then the communication will not happen. If c.com breaks then the communication will not happen. If c.com shuts down then the communication will not happen. If c.com's instance gets taken over by management that doesn't want person1 and person2 to talk, then the communication will not happen.
Another problem is that [email protected] and [email protected] might never meet, because they might be on [email protected] and [email protected]. This means that a community that could reach critical mass to be a common meeting place would not because it's split into a bunch of smaller communities.
Mastodon has servers going up and down all the time, and part of the reason it's able to continue functioning as a decentralized network is that as long as you're following people on a wide variety of servers then one server going down will stop some users from talking but not all of them so the system can continue to operate as a whole. By contrast, I'm posting this to one server, and it may be seen by people on a wide variety of servers, but if the one server I'm posting this to goes down the community is destroyed.
There are a few ways to solve the problem...
one method could work as something like a specific "federated network community". There would be a local community, and the local community would federate (via local mods, I presume) with communities on other instances creating a specific metacommunity of communities on many instances that could federate with other activitypub enabled communities, and if any of the federated communities go down the local community remains. If any servers posed problems they could cease being followed, and in the worst case a community could defederate totally from a server (at a community level rather than a server level) In that case, [email protected] and [email protected] could be automatically linked up once both connect to [email protected] (I'm thinking automatic linking could be a feature mods could turn off and on for highly curated communities), and if c.com shuts down or defederates with one of the two, [email protected] and [email protected] would continue to be able to talk through their federated network.
Another method would be something more like hashtags for root stories, but I don't know how server-server links would be accomplished under a platform like lemmy, kbin, or lotide. I don't know how hashtags migrate on mastodon type software and how that migrates. In that case, it might be something like peertube where a network is established by admins (or users, I don't know) connecting to other servers manually.
Finally, I think you could implement the metacommunity without changing the entire fediverse by having the software auto-aggregate metacommunities. You could create a metacommunity community1 on a.com that would then automatically aggregate all posts on communities called community1 on all known servers. The potential downside of this is you could end up with a lot of noise with 100 posts of the same story, I haven't thought much about how you could handle duplicates so you could participate but wouldn't have 100 similar posts. In this case with respect to how to handle new posts, each metacommunity would be a local community and new individual posts would be posted locally and federated to users on other metacommunities. If metacommunities of this sort became the norm, then the duplicates problem may be solved organically because individuals using metacommunities would see the posts on other metacommunities and wouldn't bother reposting the same story, much like how people see a story and don't repost in individual communities.
One big problem is scaling, doing something like this would definitely be a non-trivial in terms of load per community. Right now if one person signs up to one community, they get a lot of posts from one server. Under a metacommunity idea like this, if one person signs up to one community, they get a lot of posts from many, many servers. lemmy.world has 5967 total instances connected to it, and 2155 instances running lemmy, lotide, kbin, mbin, or friendica that could contain similar types of community, that's a lot of communities to follow for the equivalent of one single community, especially if some of the communities in the metacommunity have a lot of traffic in that community. You'd have to look at every known server to first see if it exists and second if it has a community appropriate for the metacommunity, and the metacommunity would have to routinely scan for dead hosts to remove from the metacommunity and live hosts that may start to see an appropriate metacommunity has been created.
I'm sure there are other solutions, but I'm just thinking of how things work within my current understanding.
Of course, for some people, the problem is one they don't want solved because it isn't a problem in their view (and that's a legit view even if it's one I'm not really amenable to). Some people prefer smaller communities, or want tighter control over their communities. For servers or communities that don't want to be brought into a metacommunity, it seems like some sort of flag to opt-out (or opt-in as the case may be) should be designed in -- I'm thinking something in the community description like a textflag NOMC or YESMC that server software would be designed to respect.
With respect to moderation, It seems to me that you could have a variety of strategies -- you could have a sort of default accept all moderation where if one instance moderates a post other instances take on the same action, or whitelist moderation where if one instance or one set of moderators on a whitelist take an action then other instances take the same action, or a sort of republican moderation where if a certain number of instances take an action then other instances take the same action, and probably an option for individual metacommunities to only accept moderation from the local community the original post came from. I suspect you'd want a choice in the matter per metacommunity instance on a server.
I think that was resolved in getaether.net, but unfortunately, development stalled and the lone maintainer isn’t active anymore. He only hosts the entry servers, but that’s it.
You could look at his solution, but honestly, fragmentation is part of federated networks. If it were distributed networks/P2P, like Aether, then fragmentation could possibly be much less of an issue as users would all be on the same network and posting to a community would send it to all peers, that hosts it for all others.
"Meta's fediverses", federating with Meta to allow communications, potentially using services from Meta such as automated moderation or ad targeting, and potentially harvesting data on Meta's behalf.
"free fediverses" that reject Meta – and surveillance capitalism more generally
The free fediverses have a lot of advantages over Meta and Meta's fediverses, some of which will be very hard to counter, and clearly have enough critical mass that they'll be just fine.
Here's a set of strategies for the free fediverses to provide a viable alternative to surveillance capitalism. They build on the strengths of today's fediverse at its best – including natural advantages the free fediverses have that Threads and Meta's fediverses will having a very hard time countering – but also are hopefully candid about weaknesses that need to be addressed. It's a long list, so I'll be spreading out over multiple posts; this post currently goes into detail on the first two.
Opposition to Meta and surveillance capitalism is an appealing position. Highlight it!
Focus on consent (including consent-based federation), privacy, and safety
Emphasize "networked communities"
Support concentric federations of instances and communities
Consider "transitively defederating" Meta's fediverses (as well as defederating Threads)
Consider working with people and instances in Meta's fediverses (and Bluesky, Dreamwidth, and other social networks) whose goals and values align with the free fediverses'
Build a sustainable ecosystem
Prepare for Meta's (and their allies') attempts to paint the free fediverses in a bad light
Reduce the dependency on Mastodon
Prioritize accessibility, which is a huge opportunity
Commit to anti-fascist, anti-racist, anti-colonial, and pro-LGBTQIA2S+ principles, policies, practices, and norms for the free fediverses
The free fediverses should work together with people and instances in Meta's fediverses and on Bluesky whose goals and values align with the free fediverse
Many of the Meta advocates I've talked to share the free fediverses' long-term goal of building a sustainable alternative to surveillance capitalism -- and the same is true for people on Bluesky. So there are likely to be situations where some of the people and instances in Meta's fediverses and Bluesky wind up as situational allies to the free fediverses.
A few areas where collaboration could be very useful:
A key principle of organizing is meeting people where they are.
Moderation on decentralized networks is a shared challenge.
Bringing concepts similar to Bluesky's custom feeds to the fediverses, and more generally focusing on human-focused and liberatory (as opposed to oppressive) uses of algorithms in decentralized social networks designed from the margins.
Meta's fediverses, Bluesky, and the free fediverses are all vulnerable to disinformation.
Transitive defederation -- defederating from instances that federate with Threads as well as defederating from Threads -- isn't likely to be an all-or-nothing thing in the free fediverses. Tradeoffs are different for different people and instances. This is one of the strengths of the fediverse, so however much transitive defederation there winds up being, I see it as overall as a positive thing -- although also messy and complicated.
So the recommendation here is for instances to consider#TransitiveDefederation: discuss, and decide what to do. I've also got some thoughts on how to have the discussion -- and the strategic aspects.